The SCSI and TCP protocols are well known within the art of computer science. In brief, SCSI is a standard specifying the interface between devices that were originally controllers and peripherals in computer systems. The SCSI architecture is a client-server architecture wherein clients and servers are called “initiators” and “targets,” respectively. Initiators send service requests to targets and receive responses from targets.
A target is a collection of logical units. Each logical unit contains a device server, one or more task sets (queues) and a task manager.
SCSI recognizes two types of requests: device-serverrequests and task-management requests. The device server processes the device-server commands while the task manager is responsible for task management.
A device-server request is a SCSI command for execution on a logical unit, such as a block read/write command. Each device-server request defines a unit of work for a logical unit. Within a logical unit, a task represents a unit of work.
A SCSI task is an execution context a target creates for a SCSI command or a series of linked SCSI commands. A new task is created for each single command, while the same task is used for all the commands in a series of linked commands, also referred to as a “chain of commands.” A task persists until a command (or a series of linked commands) completion response is sent or until the task is ended by a task management function or exception condition. The initiator sends the next linked command in a series of linked commands only after the current command completes. That is, only one pending command exists per task. From the initiator's point of view, the device server is not multi-tasking; a task executes until it completes. This property allows initiators to implement, for example, read-modify-write commands using linked commands.
Task management requests control the execution of tasks. Examples of task management requests include aborting a task, clearing an exception condition and resetting a logical unit. The task manager manages task queues and serves task management requests.
A task may be in one of four states: dormant, enabled, blocked, and ended. A task is added to the task queue as enabled or dormant and is removed from the queue when it is in the ended state. A task executes (i.e., becomes a current task) only if its state is enabled. A task state changes from enabled to ended if it successfully completes or if a task management request aborts it. A task is terminated if an exception is encountered during its execution. When an exception happens in a task queue, a Contingent Allegiance (CA) or Auto Contingent Allegiance (ACA) condition is established for the task queue based on its configuration. The iSCSI protocol mandates ACA.
The difference between ACA and CA is in the steps of clearing them. Initiators clear an ACA condition by sending CLEAR ACA task management requests.
When an ACA condition is established all the enabled tasks in the task queue change into the blocked state. Only the tasks with the ACA attribute are allowed into the queue until the ACA condition is cleared. The blocked tasks move back to the enabled state after the ACA condition is cleared. A dormant task becomes either enabled or ended (because the initiator aborts it). An initiator may abort any task by sending a task management request.
Initiators associate each task with a task attribute by including the attribute in their request. Acceptance of a new task to a queue in the dormant or enabled state is based on its attribute and the attributes of the current tasks in the queue.
There are four task attributes, simple, ordered, head of queue and ACA. A task having the simple attribute is accepted into the task queue in the dormant state. The task does not enter the enabled state until all older head-of-queue and all older ordered tasks in the queue have ended.
A task having the ordered attribute is accepted into the queue in the dormant state. The task does not enter the enabled state until all older tasks in the queue have ended.
A task having the head-of-queue attribute is accepted into the queue in the enabled state. A task having the ACA attribute is accepted into the queue in the enabled state. No more than one ACA task exists per task queue at any time.
The above description for task queue management allows simple tasks to execute in any order in a task queue. However, a task queue may be configured with either restricted or unrestricted reordering of simple tasks. In the restricted ordering, the order of reads and writes to the same block must be preserved for simple tasks. This ensures data integrity from the initiator's point of view. The unrestricted reordering configuration does not impose any rule on simple task reordering. A target may maintain one task queue per logical unit or one task queue per logical unit per initiator.
Both initiators and targets have ports to communicate with their counterparts. The requests and responses are sent through and received from these ports. An initiator or target has one or more ports. Each port has a unique identifier.
Each request includes its initiator and target port identifiers. These identifiers are in a “nexus object” in the request. In addition, the nexus object optionally contains an identifier for the logical unit and the task. The logical unit identifier is included if the request is destined for a particular logical unit. Similarly, the task identifier is included if the request is for a specified task. If the nexus object of a request does not include a task identifier then the corresponding task created in the target is an “untagged task.” It is assumed that an untagged task has a simple task attribute. Only one untagged task may be in a task queue. The nexus object of a SCSI command request includes the logical identifier as a SCSI command request is destined to a particular logical unit.
SCSI is described more fully in the SCSI-3 Architecture Model (SAM), available at www.ansi.org as ANSI X3.270-1996, in the SCSI Architecture Model-2 (SAM-2), available at ftp://ftp.t10.org/t10/drafts/sam2/sam2r22.pdf, and in the references mentioned therein. However, revision 22 of SAM-2, dated Jan. 22, 2002, is not prior art.
The iSCSI protocol maps the SCSI remote procedure invocation model over the TCP protocol. iSCSI requests carry SCSI commands, and iSCSI responses carry SCSI responses and status. iSCSI also uses the request-response mechanism for iSCSI protocol mechanisms.
iSCSI is described more fully in iSCSI, available at http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-11.txt, and in the references mentioned therein. However, iSCSI, dated Mar. 1, 2002, is not prior art.
Distributing a SCSI target leads to distributed task queue management over storage processors, computing platforms with networking capabilities for housing the iSCSI target, SCSI target, or block-storage functions. Distribution implies that multiple storage processors may receive SCSI requests for the same logical unit at the same time. Simultaneous per-LU requests will interleave the execution of SCSI requests if these processors do not exchange information about the states of their task queues. SCSI requests, however, cannot be interleaved arbitrarily.
Accordingly there is a need for a distributed SCSI solution wherein request execution does not violate the SCSI task queue management rules.
The iSCSI layer in a target orderly delivers SCSI requests to the SCSI layer. The iSCSI initiator assigns a monotonically increasing session-wide sequence number for each iSCSI request except for immediate requests. The session-wide sequence numbering defines the order. When the iSCSI layer is distributed over storage processors, the individual iSCSI layer in the storage processors receives only a subset of the iSCSI request, creating gaps in the iSCSI queue. This gap prevents delivery of non-immediate requests to the SCSI layer.
Thus, there is a need for a protocol to fill gaps in a distributed iSCSI environment and to enable the processing of requests.
The iSCSI PDU transmitted from the initiator to target carries a maximum command sequence number (MaxCmdSN) and an expected command sequence number (ExpCmdSN). The initiator uses the ExpCmdSN and MaxCmdSN from a target to determine the receiving window of the target. The iSCSI target does not transmit the MaxCmdSN less than the ExpCmdSN. Also, the target must silently ignore any non-immediate request outside of this range or non-immediate duplicates within the range. When the iSCSI layer is distributed over storage processors, the individual iSCSI layer in the storage processors receives only a subset of the iSCSI requests, leaving the individual target unable to correctly determine the current receiving window size and to communicate it to the initiator.
Accordingly, there is a need for a protocol to determine the receiving window size and correctly handle requests inside and outside this range.
These and other goals of the invention will be readily apparent to one of skill in the art on reading the background above and the description below.